home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 406 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.3 KB  |  81 lines
  1. Path: chronicle.mti.sgi.com!austern
  2. From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: #warning
  5. Date: 20 Feb 1996 10:49:21 PST
  6. Organization: Comp Sci, University of Melbourne
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <4g91rh$kgn@mulga.cs.mu.OZ.AU>
  9. References: <270631188wnr@pires.co.uk> <4ftd0p$c5s@engnews1.Eng.Sun.COM>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: 19 Feb 1996 05:29:21 GMT
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBVAwUBMSoXwky4NqrwXLNJAQE+cAH/XEofI8x1JBX6h0t4iPnkus15HWH2qDST
  14.     Tj5jlK7/Cl1B4cBI8qIickFYZXCeM7sde2EiegLn27xWCzhZk78+Qw==
  15.     =XkTc
  16. Originator: austern@isolde.mti.sgi.com
  17.  
  18. clamage@Eng.Sun.COM (Steve Clamage) writes:
  19.  
  20. >Martin Bonner <mbonner@pires.co.uk> writes:
  21. >>Following up from the discussion of "#if XXXX", is there
  22. >>any chance of getting "#warning" into the standard? Or is it
  23. >>too late
  24. >>
  25. >>It would be useful.  
  26. >>It would be easy to implement.  
  27. >>It would achieve something that cannot be achieved in any other way.  
  28. >>
  29. >>(Have I forgotten anything?)
  30. >
  31. >Yes, you forgot to say how it differs from #error, which is already in the
  32. >draft (and in Standard C). The description of #error says only that it
  33. >"causes the implementation to produce a diagnostic message that includes
  34. >the specified sequence of preprocessing tokens."
  35.  
  36. Isn't this a bug in the standard?  Doesn't this mean that
  37.  
  38.     #error foobar
  39.     int main() { return 0; }
  40.  
  41. is a strictly conforming program?  Yet no compiler I know of will accept it!
  42.  
  43. Surely the semantics specified for #error should say that it has the effect
  44. of making the translation unit ill-formed.
  45.  
  46. The semantics for #warning should be what is currently specified for #error.
  47.  
  48. >The standard describes valid source-language constructs and the effect they
  49. >have in an executing program. Details of compiler behavior cannot reasonably
  50. >be discussed without placing undesirable constraints on implementations.
  51.  
  52. I disagree.  I think it would be quite possible to specify appropriate
  53. semantics for #error and #warning without placing any undesirable constraints
  54. on implementations.
  55.  
  56. As far as I can see, the only problem with #warning is not lack of
  57. usefulness or difficulty of implementation, it is difficulty of
  58. specifying appropriate semantics for it.  This difficulty is in part
  59. caused by the existing structure of C++ draft standard.  If the C++
  60. standard were structured like say the Ada standard, then it would be
  61. very easy to state such things in "Implementation Advice" sections.
  62.  
  63. Another part of the problem is that although every compiler I know of
  64. has a distinction between warnings and errors, the draft C++ standard
  65. has no such distinction.
  66.  
  67. Nevertheless, I think these difficulties to not present any significant
  68. obstacles to #warning.  It would be easy to fix the semantics for
  69. #error and specify the semantics for #warning as I described above.
  70.  
  71. --
  72. Fergus Henderson                 WWW: http://www.cs.mu.oz.au/~fjh
  73. fjh@cs.mu.oz.au                  PGP: finger fjh@128.250.37.3
  74. ---
  75. [ To submit articles: Try just posting with your newsreader.  If that fails,
  76.                       use mailto:std-c++@ncar.ucar.edu
  77.   FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  78.   Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  79.   Comments? mailto:std.c++-request@ncar.ucar.edu 
  80. ]
  81.